A java virtual machine (JVM) has garbage collection (hereinafter simply referred to as “GC”) as a memory management function. GC is utilized in the related art (see Japanese Laid-open Patent Publication No. 59-158459, for example).
GC is a function of automatically releasing a portion of a memory area (hereinafter referred to as an “object”) dynamically allocated by application software that is not used any more. In this event, objects being used are rearranged to be continuous in order to create a continuous unused area on a heap area (while this process is occasionally specifically referred to as “compaction” for differentiation, this process is also included in GC herein). In addition to the JVM, C# Common Language Runtime (CLR) also has GC, for example. GC is thus widely employed.
In a process (such as a virtual machine) implementing a memory management function through GC, in the case where application software provides a dynamic object generation request, objects are allocated to a heap area in a virtual memory space 50 of the process. GC automatically releases an object determined to be unnecessary, of the objects dynamically allocated on the heap area by the application software. In general, there are various types of heap areas according to their usage. Herein, the term “heap area” refers to a memory area to which a group of objects as possible targets of GC are to be allocated.
As objects are repeatedly generated along with execution of the application software, the heap area is gradually filled up, which leads to a deficient free capacity not allowing generation new objects. When no more new objects can be generated, GC is executed. GC frees objects that are not used by the application software and thus are determined to be unnecessary. GC thus secures a free capacity for allocation of new objects.
In one scheme of GC, a continuous area in a virtual memory space 50 is acquired/managed as a heap area in order to increase the processing speed (improve the efficiency of sequential examination of objects in the heap area, improve the cache efficiency). Transitions between object allocation states on a continuous heap area 130 will be described briefly below.
FIG. 1 illustrates an exemplary object allocation state on a continuous heap area 130. Objects 100, for which dynamic generation requests are provided from application software, are allocated to be continuous on a heap area. The objects 100 are allocated sequentially in the direction from a lower address toward a higher address of the heap area.
FIG. 2 illustrates an exemplary state in which a free area 120 on the continuous heap area 130 is deficient. As objects are repeatedly generated, the heap area is filled up with an object-allocated area 110. The free capacity in the heap area is deficient, which does not allow generation new objects. GC is executed when the state of FIG. 2 occurs.
FIG. 3 illustrates an exemplary state immediately after execution of GC on the continuous heap area 130. GC releases objects determined to be unnecessary. Meanwhile, GC leaves objects determined as being used 105 (hereinafter referred to as “surviving objects”) in the heap area. The surviving objects 105 are collected on the lower address side of the heap area. A free area 120 for allocation of new objects is secured on the higher address side of the heap area.
In the case where a large number of surviving objects 105 remain in the heap area even after execution of GC, which prevents securing of a free area 120, an out-of-memory error is triggered.
In the above scheme of GC, a continuous memory area in a virtual memory space 50 of a process is allocated as a heap area. However, a memory area usable as a heap area may be divided to be fragmented under the influence of an area (hereinafter referred to as “non-heap-area memory area 63”) that is used for purposes other than as a heap area such as library mapping. If a memory area usable as a heap area is fragmented, the size of an area that may be treated as one continuous heap area 130 is reduced.
FIG. 4 illustrates an exemplary memory area usable as a heap area fragmented under the influence of a non-heap-area memory area 63. In the example of FIG. 4, a “non-heap-area memory area 63” is provided between a “continuous area 1 usable as heap area 140” and a “continuous area 2 usable as heap area 160”.
The presence of the “non-heap-area memory area 63” permits only one of the “continuous area 1 usable as heap area 140” and the “continuous area 2 usable as heap area 160” to be treated as a heap area. As a result, the “continuous area 1 usable as heap area 140” and the “continuous area 2 usable as heap area 160” cannot be treated as a continuous area.
There has conventionally been a scheme of GC in which a heap area is acquired from divided memory areas and not from a continuous memory area. In the scheme of GC in which a heap area is acquired from divided memory areas, divided discontinuous memory areas are used as a heap area, and therefore the heap area can be additionally acquired irrespective of the presence of a non-heap-area memory area 63.
However, the scheme of GC in which a heap area is acquired from divided memory areas and not from a continuous memory area is significantly affected by the following drawbacks, and is currently rarely used.
In the scheme of GC in which a heap area is acquired from divided memory areas and not from a continuous memory area, the heap area is virtually treated as a continuous area by using an address management table. Therefore, in order to access each object, it is necessary to calculate the actual address of the object by way of the address management table, which significantly affects the performance. In the scheme of GC in which a heap area is acquired from a continuous memory area, for example, objects are accessed using their actual addresses, not by way of an address management table, which results in fast processing.
In addition, the scheme of GC in which a heap area is acquired from divided memory areas and not from a continuous memory area requires an extra memory area for the address management table.